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been prepared by Computer Technology Associates, Inc., 
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1 . 0 INTRODUCTION 


1.1 P.: 'pose 

The purpose of this document is to present a functional 
architecture for an Integrated Command, Control, Comniunications 
and Computation (IC^) system which is applicable to space- 
craft command and control during the TDRSS era from the 1980s 
to the early 1990s. i 

/ 

The IC** system study is concerned with the command and 
'control portion of the NASA End-to-End Data System (NEEDS) 
program. The objectives of the total 'NEEDS program are to 

provide the systems concepts, techniques and tecnnology-- 

which will increase the end-to-end data system responsiveness, 
reduce the relative cost of extracting information from 
space data and increase the degree of standardization 
throughout the system. (Reference 3) In meeting this 

objective the end-to-end process has-been-decomposed- into 

the following functional areas: 


a. 

Sensor 


b. 

Sensor-unique processing 

c . 

Ancillar 

y Data Computing 

d. 

Corjiiand 

and Control/Data System 

e . 

Space-to 

-Ground Transport 

f . 

Ground Transport (Downlink) 

g- 

Data Staging 

h. 

Support 

Computing (Ground) 

1 . 

Bets 

es 

j- 

Distribution Network 

k . 

Data Bases (User) 

1. 

End User 

' 

m. 

Mission 

Planning 

n . 

Command 

and Control (Ground) 

) 

o. 

! 

Ground Transport (Uplink) 

p. 

Ground-t 

✓ 

•/ 

p-Space Transport. (Reference 3) 
1 

1 

i 

/ 

f< 

1 

1 

1 

t ^ 

1 
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The IC^ functional architecture descrioed in this document 
brings into focus the requirements for an integrated system 
which supports the command and control portions of the 
following NEEDS areas: 

a. Command and Control (Ground) 

b. Mission Planning 

c. End User t 

d. Data Bases (User) J 

e. Distribution NetworJc 

f. Data Bases 

g. Support Computing (Ground)' 

h. Data Staging 

1 . Command and Contrcl/Data System ^ground portions) 

j. Sensor-unique Processing (ground portions) . 

The requirements which have driven this functional architecture 
are documented -.n the IC'^ System Functional Requirements 

('ie£ej.ence ?) . These requirements have been derived from 

anal>s’s of the SI4M, SME, UARS, a«nd ERBE mission desions 
as well as knowledge of the Vikir.g and Space Telescope 
iiiements . 


The IC** system described herein is a highly automated 
user-machine interactive system which allows multiple 
users the capability and flexibility to execute obseriatory 
command and control. All users (science experimenters, 
mission designers and spacecraft component engineers) are 
provided capabilities relative to requesting observatory 
responses, integrating these requests into a unified 
sequence of events, modifying these events in response 
CO observatory data and ultimately command -ng the vehicle. 
The IC'* system emphasizes die utilization of standard 


2 



interfaces, procedures and techniques which may be applied 
across a broad spectriam of GSFC missions during the TDRSS 
era. The system removes the requirement that all users 
be colocated by providing a common interface which may 
be remotely located at user facilities. The standard, 
common commana and contiol capabilities comprise a 
basis set of mission requirements. The generation of a 
system design for both this basis IC^ system and the 
extension to a design for a specific mission model will 
be accomplished in subsequent efforts for NASA GSFC by 
Computer Technology Associates, Inc. 


I 


The functional architecture focuses exclusively on command 
and control activities. However, downlink data processing 
and analysis functions are included as required to support 
the uplink process. The functional architecture provides 

the functional characteristics ahd__components_of . the__.IC^ 

system with a top-level allocation of resources (i.e., people 
and computers) to specific activities. 

* 

1.3 Acronyms and Abbreviations 


CG&V Command Generation and Validation 

CRT Cathode Ray Tube 

D/L Downlink 

GSTDN Goddard Space Tracking Data Network 

H&S Health and Safety 

IC4 Integrated Command, Control, Communication, and 

Computation 

lOS Integrated Observatory Sequence 

LRP Long Rang Planning 
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NEEDS NASA End-to-End Dat-i Sysccm 

ODC On-noaid Computer 

P4,S Planning and Schodul^nvj 

POl Period of Interest 

R/T Real-Time 

TDRSS Tr.icking and Daia Relay Satellite System 

TM Tolemetrv 

U/L Uplink 
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3.0 IC'* FUNCTIONAL ARCHITECTURE DEFINITION 

4 

The purpose of this section is to define the IC system 
functional architecture. The following information provides 
this definition: 


a. functional hierarchy 
1 b. key system features 

. c. operational activity threads 

d. interfaces. 

I 



I The functional hierarchy provides the decomposition and 

allocation of command and control functions to the elements 
within the IC^ system. The key features *-uranarize the 
ma]or capabilities of the IC^ system. Opeiacional activity 
threads illustrate the inter-relationship between the 
system elements ^ demonstrate the manner in which the key 
features are implemented and provide the order and timeliness 
in which the operations are performed. Th^ iliteTf aces 
illustrate those elements that originate or generate data 
and those elements that use the data. The interfaces also 
provide a description of the data and the data utilization 
and access techniques. 


3.1 System Introduction 


This section provides an overview of the IC^ system and 
operational activities. Key definitions are first presented 
to define ma^or terms used to describe the IC'* system 
components. The overview then defines the system elements 
and summarizes the interactions between these elements. 

The operations overview summarizes the operational activities 
and capabilities of the IC^ system. 



3.1.1 System Terminology 


f 


Key system terminology and definitions are as follows: 

a. Observatory - The observatory is the total vehicle 

that supports a specific mission. It includes science 
instruments, on-board processors and spacecraft components 
required to support the science instruments or control 
vehicle operations. ,• 

b. Science Experimenter - The science oxuerimenter is the 
initiator of science experimentation and the end-user of 
the on-board science instrument data. The functions 
performed by the science experimenter are as follows: 

1) Generation of sequences required to command 
and control the on-board science instrument 

2) Generation of comma* ds for an instrument 
unique on-board processor 

3) Analysis and interpretation of science and 

' instrument engineering data 

4) Dissemination and archival of science and 
instrument engineering data. 

c. Subsystem Elements - The subsystem elements are responsible 
for the command and control of the following on-board 
subsystems: power, thermal, data storage management, 
communications (uplink and downlink), on-board computer 
(OBC) or command memory, attitude and orbit. Subsystem 
element functions include analysis and interpretation of 
subsystem data, generation of sequences required to' 
command and control the specific on-board subsystems 
and support of all IC"* elements to produce observatory 
sequences . 

I - , ■ . ■ . 
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d. Sequences - A sequence is the definition of an instrument 
or subsystem activtiy which defines start time, duration 
and events within the activity. Inherent to a sequence 
IS specific data which adds to the sequence definition 
(i.e., power and thermal profiles of the instrument or 
subsystem during the sequence, data and commanding 
requirements, etc.). 

e. Mission Management •• Mission management coordinates and 

integrates all other elements and activities with.’n the 
IC^ system. It provides the framework_and- mechanisms - - 

whereby a unified plan of action and observatory and 
ground sequences can be oenerated. The mission management 
element provides the capability to incorporate various 
mission oojectives into a final usable form and directs 

the implementation of this detailed plan_of_action 

or sequence of events. 

f. User - User refers to the elements that interact with the 
IC"' system to control an instrument or subsystem. 

All science experimenters, subsystem elements and mission 
management are considered users of the IC'* system. 

g. Local Operations - Local operations refer to the standard, 
project-wide real-time observatory monitor and control 
functions which include transmitting command loads and 
monitoring real-time data to assure observatory nealth 

I * 

and safety. 





h. In-House Operatxons - In-house operations refer 
to real-time functions unique to a soecific 
science experimenter or subsystem user that are 
conducted at the user facility. The user facility 
may be at a location geographically dispersed 
from the local operations facility, or it may be 
at the same fviciljty but residing in a seuarate room 
or building. 

t ' 

i 

1 . Ground-Space Link - The ground-space link primarily 
i refers to the observatory communications {uplink 
and downlink) performed through TDRSS. It should 
be noted that other forms of ground-space communications 
could be applicable (i.e., GSTDN and mission unique 
facilities for communications) . However, for the 
purpose of this document, TDRSS is assimed to provide 
the .irovind-s” IOC Iu'n. 

3.1.2 System Overview 

The IC** system provides the mechanism by which the users 
command and control the ‘observatory . The IC"^ - ystem is 
highly automated iind provides the • ipability to perform 
the command and control activities n a timely manner via 
a computer based, man-machine interactive network. 

Figure 3.1-1 defines the elements which comprise and 
utilize the IC-* system. The elements are linked together 
by a computer and voice network which allows the elements 
CO communicate with one another from separate and remote 
locations. Each user has available a CRT terminal through 
which the interaction with all system elements is conducted. 
Using computer graphic interactive techniques, each user 






MISSION 

MANAGEMENT 



has the capability to: a) participate in the planning 

and conunand generation activities; b) review uplink products; 
c) assist in conflict resolution; and d) modify observatory 
sequences (either in response to conflicts or adaptively 
in response to downlink data) . Each element uses the 
interactive terminals to access system-wide data for display 
and support in creating command and control requirements. 
Additionally, each user uses the interactive terminals to 
access and monitor downlink data and to participate in the 
real-time uplink process. 

f 

I 

3.1.3 Operations Overview i 


Figure 3.1-2 summarizes the operational activities and 
capabilities of the IC^ system. Command and control activities 
are divided into four basic areas of concentration as 
follows : 


a. Long-range planning 

b. Planning and scheduling for a period of interest 

c. Command generation and validation for the contacts 
within the period of interest 

d. Real-time operations for each contact. 

A brief description of these functions follows. Detailed 
activity threads are presented in Section 3.4 of this document. 

Long-range planning is a highly manual, people interactive 
function that occurs as required throughout the lifetime of 
a mission. Long-range planning addresses the overall 
mission picture providing goals, objectives and plans for 
an extended period of time. The outputs ot long-range 

i 

planning provide ajbascline for day-to-day mission operation: . 


/ 

/ 
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FIGURE 3.1-2 OPERATIONAL ACTIVITY OVERVIEW 
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Planning and scheduling (P&S) is an automated and man-machine 
interactive activity which addresses a fixed mission period 
of interest (POI) and which occurs on a regularly scheduled 
basis throughout the lifetime of the mission operations. 

The POI IS a mission segment for which detailed scheduling 
and coordination of observatory activities are performed. 

The POI is typically on the order of one to two weeks. 

Within the POI, there are one or more contacts between the 
ground and observatory. Prior to the day-to-day planning 

I 

and scheduling operations, the TDRSS schedule is established. 
The TDRSS schedule covers a time period greater than the 
POI and is finalized by the time actual planning begins 
for the POI. TDRSS scheduling is performed of f-line"'to~'the ' 
normal PCI P&S activities. 

Routine F&S operacions begin with a planning meeting for 
the POI. At this meeting, science representatives, space- 
craft elements and mission planning”elem'ents~assess“tHe 

observatory operations and schedule ma^or observatory events 
for the POI (i.e., maneuvers, pointing agreements, high 
data rate operations) . Based* on the outputs of the planning 
■'seting, ail system users (science experimenters, subsystem 
iqineers, attitude anc. orbit subsystem engineers) cenerat 
specific sequence packages/requests for the POI. The 
combined sequences are referred to as the Integrated 
Observatory Sequence (lOS) . Associated with the lOS is a 
conflict summary defining inter— instrument , instrument_-to- 
spacecraft and observatory-to-ground conflicts. To resol. 'e 
conflicts between project elements, a coordination session 
IS held and the user request process is iterated until all 
conflicts are resolved. The output of the coordination 
session is a conflict-free IDS. After the lOS is generated 
system users have the capability to adaptively modify their 
sequences within the lOS n response to spacecraft or science 
I'strument data received during a ?Ot. 

i 
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Based on the lOS, mission management activates the command 
generation and validation (CG&V) process. CG&V is a highly 
automated process that generates the following products: 

a. Upload packages (corsnand loads) for each contact during 

the POI ‘ 

b. Uplink (U/L) and downlink (D/L) profiles for each 

} 

contact during the POI 

c. Power /thermal profiles, on-board data storage management 
strategy and OBC (or command memory) map for the POI 

d. Validated integrated sequence with respect to power, 
thermal, data storage, OBC (or command memory) and 
communications (U/L and D/L) capabilities. 

When conflicts are detected within the validation process 
the integrated sequence is modified and the coirmand generation 
and validation process is iterated until validation has beer 
completed This process is repeated as required by mission 
management to accormodate alternative observatory sequences (as 
part of the lOS) and potential adaptive comnanding requirements. 

To complete the CG&V process, mission management combines 
- 1*1 upload packages into unique sets for each uplink and 
generates the real-time procedures for each contact period. 

These procedures are then used to drive automatic operations 
during contact with the observatory. Once integrated upload 
packages are prepared, the users have the capability to 
update adaptively the command loads prior to command trans- 
mission. 

Real-time operations involve two distinct areas: local 

operations and in-house user operations. Local operations 
include the standard pro;)ect-wide real-time operational 
facility and interface with TDRSS . In-hoase user real-time 
operations include facilities and activities unique to a 
-ser or user facility. Via in-house user operations, users 
nave the cacability to mionitor real-time data and idaptivcl 
'odify uploads based upon incoming downll'^ aaca. 
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3.2 Functional Hierarchy 

Figure 3.2-1 identifies the IC^ eleir.onts involved in the 
ground processes which command and control the observatory. 

Functional decompositions for each of the elements shown in 
the overview are contained in the hierarchy charts which 
are discussed in the following sections. The functional 
hierarchies define the detailed functions for each element. 

Each element has been decomposed into the component parts 

. ’ ’ 

which are necessary to produce an IC^ system. 

I 

For science experimenters and subsystems (power, thermal, 
attitude, orbit, data storage, OBC, communications) , control 

and data acquisition/utilization are common components. • — 

The control component contains those functions necessary 
to plan and cause to be implemented on-board activities. 

The data acquisition and utilization component, which contains 
downlink-related functions, is included in this command 

and contro] analysis for completeness -and— to- insure-that-the — 

feedback of data to the comma id and control functions is 
considered in the total system design. In addition, the 
subsystem decompositions include* a mission support component . 
which contains those functions necessary to allow full 
utilization of observatory capabilities. These subsystems 
support the mission by supplying projections of capabilities, 
capacities a.nd events. The power, thermal and on-board 
data storage management subsystems aie shown in one hierarchy 
chart because their IC"^ components are similar. However, 
in implementation they are totally separate and distinct 
elements . 

The mission management element serves as the focal point 

and controlling element for all activities. Mission management 


I 

I 
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is divided into an observatory control component and a ground 
Oi>erations control component to reflect the two areas of 
responsibility. Finally, observatory monitor and control 
is decomposed into observatory control, ground control and 
data acquisition/utilization components. 
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These elements are discussed in the following paragraphs 
and fully described on the hierarchy charts. 


3.2.1 Science Experimenter Furct-ional Hierarch\ 


Figure 3.2-2 summarizes the functional hierarchy for the 
science experimenter element. The science experimenter 
element is divided into two distinct functions: 1) science 

instrument control and 2) instrument data acquisition and 
utilization. Science instrument control involves all 
activities necessary to generate instrument unique sequences 
and includes science experimenter, real-time operations to 
transmit selected sets of commands" fbf~adaptive”or'~anomaroui 
situations. Instrument data acquisition and utilization 
encompasses all downlink data processina and analysis necessary ' 
to support science instrument^ control functions, real-time 
operations and science analysis. These two functions are 
addressed in greater detail below. 


3. 2. 1.1 Science Instrument Control 

Science instrument control in^’olves the folio ing functions; 

a. all planning activities to determine integrated mission 
science requirements and to determine science instrument 
events for the POI 


b. sequencing activities to schedule instrument events 
for the* POI 
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c. sequence package development to support planning 
and scheduling activities 

d. instrument -processor management 

e. user in-house real-time opeiations. 

The science experiment planning function is divided into 
two areas mission science planning and science instrument 
planning. Mission science planning includes long-range 
science planning to establish mission gcals and t-bjecti'ves . 
This function involves coordination between all project 
(elements. Science instrument planning refers to the planning 
activities to support a specific science instrument. This 
function is responsible for specifying major instrument eviyits 
during the planning POI and for coordinating these events 
with mission managemenc. 


Instrument sequencing includes the selection and scheduling 
of all instrument events during the POI . _rhi^ function 
IS responsible for definition of pre-defined adaptive 
responses and pre-canned commanding requirements. Instrument 
sequencing provides all sequencing inputs to mission 
management and participates in the review and conflict 
resolution process to generate the Integrated Observatory 
Sequence. 


Sequence package development is an off-line process that 
generates individual sequence packages. (Refer to Section 
3.3.2 for a description of the sequence packages.) The 
sequence packages are selected and scheduled by the instrument 
sequencing function. 


Instrument processor management controls any instrument 
unique on-board processor by managing the processor memory 


/ 
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and validating instrument commands sent- to this processor. 

The in-house il-time operations function provides the 
real-time capability to request pre-canned instrument 
command responses during a cc.-.tact with the observatory. 
This function interfaces with the observatory monitor and 
control function to request that commands be sent. 

i; 

/ 

/ 

3 . 2 . 1 . 2 Instrument Data Acquisition and Utilization 


Instrument data acquisition and utilization involves the 
following functions: 

a. preparation for real-time operations 

b. instrument real-time and near real-time activities 
to support in-house operations 

c. instrument data analysis 

d. archival of science data.. 

Preparation for real-time operations includes definition 
of data necessary to support the observatory monitor 
and control element to process and monitor real-time instrument 
data. This function defines instrument parameters to~be displayed 
by observatory monitor and control and defines conversion 
factors, alarm limit? and required responses for these parameters. 
Also, adaptive response parameters and associated responses 
are defined. The instrument real-time and near real-time 
support function is involved in in-nousc operations only.. 

This function is respons-’.ble for proces,sing raw data and generating 
in-house displays and is responsible for monitoring instrument 
data in-house. The in-house data monitor function monitors 
instrument data (either the raw data as processed by the 
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instrument data collection function or. the real-time displays 

% 

from observatory monitor and control element) . Also, the in- 
house data monitor fun<.tion interfaces with observatory monitor 
and control to support real-time operations. 

The instrument data analysis and data archive functions involve 
generation of science end products, analysis of these products 
and archival of th«; final data and products. Thjse functions 
do not directly support science instrument control and are 
included for completeness only. 

3.2.2 SuLsysuem (Power, Thermal, or Data Storage Management) 
Functional Hierarchy • 

Figure 3.2-3 summarizes the functional hierarchy for the power, 
thermal and data storace management subsystems. These three 
subsystems contain similar functions, and for the purposes of 
this uccument they are shown only once. 


This subsystem element is divided into three distinct functions: 

1) subsystem mission support, 2) subsystem control and 3) subsystem 
data acquisition and utilization. Subsystem mission support 
involves support for the planning and command generation and 
validation activities. Subsystem control involves those activities 
required to generate subsystem unique sequences and includes 
real-time operations to transmit selected sets of commands 

for anomalous situations. Subsystem data acquisition and 
utilization encompasses all downlink data processing and 
analysis necessary to support 1) the subsystem control function, 

I 1 

2) real-time operation,s and 3) subsystem data analysis. The 
data acquisition and utilization function -is similar to the 
one for the science experimenter (section 3. 2. 1.2). 
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Variations unique to the subsystem ar4> covered on the hierarchy 
chart. The remaining two functions are addressed in greater 
detail below. 

3 . 2 . 2 . 1 Subsystem Mission Support 

Subsystem mission support involves the following functions: 

a. support of observatory activities 

b. support of the command generation and validation 
process. 

The planning support function generates subsystem predicts ~ 
(power, thermal and data storage management) for the POI. 

These predicts are used by all system elements as required 
during POI planning. 

The command qeneratjon and validation -support-function- — -- - 

IS responsible for validating observatory sequences and 
assuring that no constraints are violated relative to 
power, thermal and on-board data storaqe. Also, this 
function generates power, thermal and data storage profiles 
based on the observatory sequence for POI. 

3. 2. 2. 2 Subsystem Control 

The subsystem control functions are similar in practice to 
those for the science experimenter (section 3.2.1. 1) with 
two exceptions. First, a mis.sion science planni.iq function is not 
included as this function is primarily science related. 

Second , a subsystem processor management function is 

not included as it is jassumed that the systems use the flight 

processor (OBC or conrhand memory) for commandinq purposes. 
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3.2.3 OBC or Command Memory Management Functional Hj.erarchy 


Figure 3.2-4 summarizes ihe functional decomposition for 
the OBC (or command memory) management subsystem. This 
element is divided into three distinct functions: 1) mission 

support/ 2) subsystem contro’ and 3) data acquisition and 
utilization. Mission support includes support of the planning 
and command generation and validation processes and generation 
of commands for those instruments or subsystems utilizing 
the OBC or command memory. The control function involves 
those activities required to generate sequences unique 

I 

to this element and includes real-time operations to transmit 
selected sets of commands for anomalous conditions. 

Data acquisition and utilization encompasses all downlin)t 
data processing and analysis necessary to support 1) the 
control function, 2) real-time operations and 3) post-pass 
processing, analysis and data archival. The control 
function IS similar to the one for the power, thermal and 
data storage subsystem (section 3. 2. 2. 2). Variations unique 
to OBC or command memory are addressed in the hierarchy 
chart. The remaining functions aVe addressed in greater 
detail below. 

3.2. 3.1 Mission Support 

Mission support is decomposed into the following functions: 

a. planning support 

b. command generation and validation support 

c. command generation. 

Planning support provides information to support planning 
activities for the POI. This information includes predicts 
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relative to amount of memory available for POI and potential 
timing constraints for memory usage. Command generation and 
validation support provides a portion of the lOS validation. 

This function generates a memory map or 03C loading for 
each uplink within the POI and flags conflicts whore 
constraints are violated. This function also summarizes 
available memory or OBC capacity following each upload in the 
POI. The com:nand generation function generates commands 
(from command mnemonics) for those sequences utilizing the 
OBC or command memory. 

3.2. 3.2 Data Acquisition and Utilization 

This function is similar to the one Cor the science 
experimenter element (section 3.2. 1.2) with the following 
exceptions. A nost-.->ass function is included to update the 
memory map or OBC loading post-contact. Also, the data analysis 
function IS abbreviated to include trend analysis only. 


3.2.4 Subsystem (Communications) Functional Hierarchs^ 

Figure 3.2-5 summarizes the communications subsystem 
functional breakdown. The communications element is divided 
into three distinct functions: 1) subsystem mission support, 

2) subsystem control and 3) subsvstem data acquisition and 
utilization. Subsystem mission support involves support 
for the observatory planning and generation of observatory 
command files. Subsystem control includes those activities 
required to generate subsystem unique sequences and includes 
real-time operations to transmit selected, sets of commands 
for anomalous situations. Subsystem data acquisition and 
utilization encompasses all downlink data processing and 
analysis necessary to support 1) the communication subsystem 
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control function, 2) real-time operations and 3) data 
analysis. The control and data acquisition /uti li 2 ation 
functions are similar to those previously described 
(sections 3. 2. 2. 2 and 3. 2. 1.2, respectively). The mission 
support function is summarized below. 

3. 2. 4.1 Subsystem Mission Support 

1 

Subsystem mission support involves the following functions: 

a. planning support 

b. support of command generation and validation 

c. command generation 

d. post-pass activities. 

The planning and command generation and validation 
support are similar to those functions for power, thermal 
and data storage subsystems (section 3. 2. 2.1). Variations 
unique to the communications element are covered on the 

hierarchy chart. The command generation function is 

responsible for generating the upload packages for transmittal 
to the observatory. The post- pass function updates the uplink 
profiles (as generated by the command generation and 
validation support function) based on actual real-time 
commanding. ' “ ’ _ _ . 

3.2.5 Attitude Subsystem Functional Hierarchy 

Figure 3.2-6 summarizes the functional decomposition for 
the attitude subsystem element. This element is divided 
into three distinct functions: i) mission support, 2) attitude 

subsystem control and 3) data acquisition and utilization. 

The mission support involves support of the planning and 
sequencing activities and includes support of the off-line 
sequence development functions. Attitude subsystem 
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control involves those activities required to generate 
attitude system unique sequences and includes real-time 
operations to transmit selected sets of commands for anomalous 
situations. Data acquisition and utilization is identical 
in form to the science experimenter function (section 3.2.1.ii)* 
The details of data acquisition and utilization are shown 
in Figure 3.2-6 and are not repeated in the text. 

Mission support and attitude subsystem control are addressed 
in greater detail below. / 

\ 

3. 2. 5.1 Mission Support ‘ 

Mission support includes the following functions: 

a. planning support 

b. sequencing support 

c. new sequence development support. 

Planning support pro''ides attiti.de predicts for the Poi 
in support of planning and scheduling activities. These 
predicts are used by all system elements for planning 
purposes during the POI preparation. 

The sequencing support function provides the capability 
to design and schedule attitude maneuvers as required by 
science or orbit. This support supplies attitude profiles 
as required during the sequence preparation activities. 

New sequence development support is responsible for the 
supply of detail ti.ming and pointing information to users 
during their sequence development. Tiis effort involves 
specification of such items as slew rates and durations 
in order that dependent activities can be fully coordinated. 
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Science examinatxon of targets of opportunity or steering 
during burns for orbit adjust are thus achieved. 

3 . 2 . 5 . 2 Attitude Subsystem Control 

The subsystem control functions are similar to those for 
the science experimenter with two exceptions. First, a 
mission science planning function is not included as the 
attitude subsystem is a support function and not a mission 
driver. Second, a subsystem processor management function 
is not included as it is assumed that the central OBC 
or command memory is utilized. (Should this assumption 
be false a function such as subsystem processor__management 
will be added.) 

3.2.6 Orbit Subsystem Functional Hierarchy 

Figure 3.2-7 summarizes the functional decomposition for 
the orbit subsystem element. This element is divided 
into three distinct functions; 1) mission support, 

2) orbit subsystem control and 3) data acquisition and 
utilization. Mission support involves support of the 
planning and sequencing activities and includes support 
of the of^-line sequence development functions. Orbit 
subsystem control involves those activities reauired to 
generate orbit uni''ue ev'cnts and to modify sequences. Data 
acquisition and ut_lization is identical in form to the 
science experimenter (section 3. 2. 1.2). The details of data 
acquisition and utilization are shown on Figure 3.2-7 
and are not repeated , in the text. Mission support 
and orbit subsystem control are addressed in greater detail 
below. 

■ I 
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3 . 2 . 6 . 1 Mission Support 




Mission support includes the following functions: 


a. planning support 

b. sequencing support 

c. new sequence development support. 

I 

) 

Planning support provides orbit predicts for the POI 
' in support of planning and scheduling activities. These 
predicts are used by all system elements for planning 
purposes during the POI preparation. 

The sequencing support function provides the capability 
to design and schedule orbit changes as required by 
mission specifications or activities. This support supplies 
orbit profiles and associated data such as ground track 
as required during the sequence preparation activities. 


New sequence development support is responsible for the 
supply of detail timing- and orbit information to users 
during theif sequence development. This effort involves 
detail specification in order that dependent activities 
can be fully coordinated. Science examination of targets 
of opportunity and coordination with attitude for steering 
during burns fcr orbit adjust are thus achieved. 


3.2. 6.2 Orbit Subsystem Control 


The subsystem control function's are 
the science e<perimentcr with three 
a mission science planning function 
as the orbit subsystemi is a support 


similar to those for 
exceptions. First, 
IS not included 
function and not a 
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mission driver. Second, a subsystem . processor manaqement 
function IS not included as it is assumed that the central 
OBC or command memory is utilized. Third, orbit 
does not utilize in-house real-time operations as tne 
launch process will be managed through independent facilities 
and, except for precanned shut down commands (which are 
generated under sequence package development), no real-time 
operations during nominal mission activities are 
anticipated. < 

> 

3.2.7 Mission Manaqement Functional Hierarchy 
I 

Figure 3.2-8 summarizes the functional decomposition for 
the mission management element. This element is divided 
into two distinct functions: 1) observatory control and 

2) ground operations control. The observatory control 
function IS responsible for integrating all user requirements 
for commanding the observatory from conception of science 
desires through final command package preparation. The 
ground operations control provides schedules, procedures 
and constraints for performing all ground operations. 

3 . 2 . 7 . 1 Observatory Control 

Observatory control is divided into the following functions; 

a. plannino 

b. sequencing 

c. comihand generation. 

The planning function supports mission science planning 
activities by generating long range schedules based upon 
science integration of mission goals and objectives. 


/ 

i 
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The function also coordinates the observatory planning 
activity by integrating user requests for major events 
during the POI and conducting meetings/roviows to resolve 
conflicts between the users. The sequencing function 
integrates all user sequencing requests thereby generating 
the lOS. Conflict detection is performed relative to the 
lOS. This function conducts the iteration process to 
resolve conflicts and generate the lOS. The command ' 
generation function activates the subsystem elements 
to perform command generation and validation. Detected 
conflicts are reported to this function for subsequent 
resolution. 

3. 2. 7. 2 Ground Operations Control 

The ground operations control function is divided as 
f ol 1 ows : 

a. vj round/ space link schedule 

b. ground operations schedule 

c. ground processing schedule 

d. real-time operations requirements 

e. post-pass. 

The ground /space link schedule specifies TOKSS support 
requirements and cooidinates these requirements directly 
with the ground/spaco link (TDRSS) . This function 
provides all inputs to TDF.SS including observatory ephemeris 
states : or all contacts and transmitter freuuencies as 
appropr latv' . 

The ground operations schedule function urovidos ground/ 
oorsonnel actiVaty schedules lot meetings, shuts, ptoduet 
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duo times, etc. The schedule produced provides the f ra*me- 
work by which all mission operation^i are performed. 

The ground processing schedule function schedules ground 
events that are to occur or to be controlled automatically.' 
Examples include 1) cut-off points which dictate tjmes 
bi which selected events are to be completed (i.e., command 
file generation), 2) software programs to run at specified 
times and 3) transfer of data between data bases based on 
t ime . 


The real-time operations function coordinates all real-time 
events that are to occur durinq each contact. This function 
develops real-time procedures which schedule- and control 
real-time operations. These procedures ma^ be general 
for many contacts or may contain events unigue to a specific 
pass (i.e., adaptive science uulinks for a given contact). 

The post-pass function activates -the-communication-systcm- 
to update protiles based on actual real-time operations. 

3.2.8 Observatoiv Monitor and Control Functional Hierarchy 


Figuie J.2-9 summarizes obseivatory monito* and control 
docompos It ion . This element is divided into throe 
distin.ct lunctions: 1) real-time observators control, 2) 

ground control and J) data acquisition and utilization. 

The observatory coatiol tunetion implements the real-time 
procedure to transmit command loads, monitor the uolink 
piocoss, cause safinn oi adaotivo commands to be trains- 
mitted and ineorporato command rcnuosts f i om user in-housc 
facilities duiinvi real-time operations. Tlie around contia’>l 
function assiucs cv^ui •'mont , sottwaie and personnel 
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availability to support real-time operations. 

The data acquisition and utilization function is divided 
as follows: 

a. preparation for real-time operations 

b. real-time and near- real-time support: real-time 

data monitor and data collection/transfer 

c. quick look trend analysis. 

Preparation for real-time operations is responsible for 
display format generation and for incorporation of user 
requirements into the downlink processing events 
(i.e., instrument/subsystem data conversion factors; alarm - 
limits and adaptive uosponse limits) . The real-time 
data monitor function is responsible for displaying the 
data, checkino for pre-specif led alarm or adaptive conditions 
in the ata and monitoring all data as displayed. This 
function coordinates downlink events 'with' the" instrument - 
or subsystem in-house operations in event of anomalies 
or special observatory operations. The data collection 
and transfer function collects all incoming data, performs 
data conversion, sorts the data and transfers the data to 
other system elements per the real-time procedures. 

The quick look trend analysis function performs a quick- 
look analysis of the displayed data and provides a post-pass 
health and safety status of the observatory and of the 
uplink and downlink process. 
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3 . 3 Key Features 


The following subsections describe the key features of the 
IC*! system. These features provide underlying capabilities 
which allow the system elements to perform the required 
activities. These key features are the outstanding 
characteristics of the IC^ system. The interactive user 
and the facilities available to him, the sequences packages, 
the adaptive update capabilities and the user specific 
in-house real-time operations are as follows. ' 

! 

3.3.1 Interactive User 

f 

The IC^ system users have the capability to interacjt 

directly with other operationa) elements of the system. 

Users have the capability to independently develop instrument 
or subsystem operational scenarios and then present the 
control requirements necessary to achieve the desired 

activities to the system in the form of sequence packages. 

The IC** system combines the sequence packages into an IDS. 

The user can interacti\ ely review and modify the lOS at 
many points during the operations cycle. The user may 
direct the system to check newly developed sequence packages 
against the lOS to detect conflicts or excessive use of 
observatory capacity. The interactive user has the 
capability to modify, add or remove sequence packages at 
any time from the initial generation of an lOS through 
the actual real-time uplink period. 

To achieve this interactive caoabilits, the IC * system 
provides the following related servictis: 


a. grapnic and textual displays 

b. information access 

c. procedure access* 
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General purpose hardware/software subsystems provide these 
services and enforce common interfaces between users. 

These services are described in th,e following paragraphs. 

3. 3. 1.1 Displays . __ _ 

The primary means of generating and presenting data within 
the IC** system is through graphic and textual displays 
which are maintained by underlying computer systems. ’ - 
Utilizing CTRs (or equivalent devices) » sequences of events, 
schedules, command files and subsystem data can be 
displayed by all users. Each user has the capability 
to generate new displays at the user interactive terminal 
using keyboard for textual input and light pens, joysticks 
or digitizing tablets (as appropriate) for graphical 
input. Inter rctive display software and hardware allow 
the users, both local and remote, to access and generate 
displays which are maintained in standard interface formats. 

Display acces.s is provided via menu selection.- A user 
selects first from a master menu and then from selective 
menus until the desired information is obtained. The 
technique used to obtain a display defining uplink schedules 
a.id the technique used to obtain a sequence package display 
is the same. Different menus lead to different data sets,' 
but the operation is identical. Similarly, standard 
development skeletons are available to users which provide 
a common format for generating displays while allowing 
each user to tailor the actual content of the display 
to his needs. (For a detailed example, refer to Section . 
3.3.2, Sequence Packages.) 
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Each display in the IC** system is stored in a standard 
format chereby allowing every user to view all internal 
dcta. The capability to partition a display into 
totally independent areas (i.e., de^in^ "windows") is 
provided such that a user may display information from 
several cifferent data sources simultaneously. An example 
of the use of this interactive capability arises during 
interscience coordination. When several science users 
located at remote sites wish to develop a joint experiment, 
they each display portions of the others' sequence packages 
on their terminal while communicating via a voice network. 
Utilizing a light pen to highlignt specific items of interest 
or move timelines about on the display, they aenerate a 
coordinated plan. 

3. 3. 1.2 Information Access J — — - - - - 

I 

The IC*^ j-ystem allows all users to access system-wide 
data. B\ maintaining data in a standard interface format 
and orionti.'g this format toward the interactive user, 

commo 1 access is proviaed. Each user develQps__several - - 

difierent types of data dvrring the operations cycle; i.e., 
seoucnce packages, telemetry data display packaqos (providing 
information such as conversion factors) and parameter packets 
(for adaptive use in real-time commandinq) . Additional 
examples of 'system data are the lOS, command packages and 
indexes and real-time procedures. The IC^ system allows 
each usei to access the various d.ata for display and to 
modifv or reolace the content of user data packages. 

1 . 3 . 1 '. 3 ' Piocodure \ccess 

The IC"* svstem piovideS' various dc\ eloomental and validation 
prccodures. Included iln those aio the capabilities to 
combine individual user, sooucnces into an intt;, -rated 
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sequence and to validate the combined sequence. (See 
Section 3.4 Operational Activity Threads). The individual 
users have the capability to modify the observatory sequence 
and to trigger appropriate validation procedures. Thus, 
a user may produce a potential sequence, request selective 
or complete validation (as necessary) and determine the 
implications of this potential modification without disrupting 
the normal overall flow of events. The 10“* system is 
capable of recognizing a potential change w) ich lias 
successfully met all acceptance criteria (via validation ’ 
procedures) ‘ and incorporating the new sequence upon user 
r^equest . 

) 

3.3.2 Sequence Packages - _ 

The standard method of defining observatory requirements 

and activities is via sequence packages. A sequence package 

contains information in two forms: graphical and tabular. 

The graphical representation is uscd,in__the_de.sign of a 

new activity profile for an experiment or subsystem and 

in the illustration of desired or actual activities or 

observatory events (Figure 3.3-1)^. The tabular data is 

used to communicate detailed instructions from the user 

> 

to (ultimately) the observatory (Figure 3.3-2). Seeuence 
packages are generated using standard interactive terminals 
which provide the support required. The user interactive 
term.inal with support software provides skeletons for 
sequence packages, standard storage techniaues and standard 
interfaces. Each user specifies the detail content of 
a sequence package within the confines of the skeleton 
to match the needs of the experiment or subsistem. 
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A sequence package is the total and oni-; description of 
an on-board activicy performed by an c-x^>eriment or subsystem. 
All control over the observatory results from utilization 
of data contained in the sequence packages. Each sequence 
package is a self contained item which defines a unique 
activity. Thus, if an exoerimenter has several experiments 
to run during a ?0I, chere is a corresponding number of 
sequence packages. Similarly, if the same experiment is 
to run several times within a POI, tlierc are several 
sequence p. ckages each containing the time associated with 
the reoccurance of the experiment. 

The system is designed such that mission management 

calls ,:or specific inputs to the operational cycle at 
various times. The users comply by supplying sequence 
packages. This activity is done via machine-to-machine 
(or data base-to-data base) interaction with appropriate 
checks made by tne mission management software. 

A user develops sequence packages off-line from the day- 
to-day operational activities. In fact, for many activities, 
sequence packages are developed befo-e the observatory is 
launened. A predefined sequence package can then be selected 
by the user during the P&S cycle ana the actual start times 
inserted to define placement within the POI and to replace 
the relative times used during sequence package development. 

Figure 3.3-1 illustrates the graphic centerts of a typical 
seque.nce oackage as it would be viewed on a user interactive 
terminal. The caoability to present selectively any portion 
of the seauence package allows more information (graphic 
or tabular) to be hold in a seauence package than can be 
displayed at one time. Thus, while generatiiig a new 
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sequence, each line of the graphic may be developed while 
showing only other relevant data. Similarly, portions of 
mission support information (Figure ' 3. 3-3) may be displayed 
while developing, modifying or comparing sequences. The 
graphic displays are developed using a light pen, ;)oystick 
and/or digitizing tablet and keyboard supported by software 
which presents features of a sequence which the user selects, 
modifies or moves about to complete each portion of the 
picture. Additionally, software is provided to take tabular 
data (Part II of a sequence package) and generate equivalent 
graphics or vice versa. For a standard item such as an 
instrument or subsystem power profile, the user may 
draw the graphic which then generates the tabular data, or 
the user may enter the tabular data and have the graphic 
support package draw the picture. __ 

Standard designators are used by all' sequence package 
generators such that the integrating software may detect 
conflicts. For example, in Figure 3.3-1 under the e.xclusive 

profile, graphic "X" might be an .'indicator _that_this 

experiment cannot execute while experiment "X” is active. 
Similarly, ' Y" might indicate that there is a requirement 
for the entire observatory to be pointed at specific tarqets 
during the indicated time periods. Note that in a pointing 
situation, the design process is supported by the attitude 
control subsystem to generate required attitude profiles 
and oy mission management to assure inter-science coordination. 

The attitude control subsystem and tne experimenter may transfer 
tno pointing portio i of their sequence packages back and forth 
between themselves >.shilo generating the desired attitude 
profile. The attitude control subsystem sequence package 
and tne experiment sequence pacKage are, in this way, 
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FIGURE J.3-3 Sequence Generation Baseline Graphics 

Note User may select to display any (or none) of the graphics while defining, modifying, or positioning 
a sequence nackaqe 


developed in parallel. Support functions such as attitude, 
orbit or corununications will, in addition, develop long ^ 

range projections within the sequence package format. 

% 

The user has the capability to modify or combine existing 
sequences. Therefore, if an experimenter has already 
developed a basic sequence, he will modify that sequence 
to produce a sequence package for a special situation. 

The graphic and tabular data associated with the basic 
sequence are modified and the new sequence package 
generated by adding, deleting or modifying items. Thus, as 
the mission matures, the sequence generation process 
becomes one of selecting the sequence most closely resemblina 
thcit desired and modifying as required. 

The tabular data given in Part II of a sequence package is 
used by support subsystems to determine power, thermal, data 
storage, data transmission .and command requirements. Each 
user fills in the appropriate values while designing or 
modifying a sequence. The sequence development support 
software prompts the user tc fill in each item of the 
tabular data which is not directly obtainable from a graphic. 
Using the prompting technique, the completeness of a seauence 
package is determined. For example, if a previously 
developed scKJuence package is being modified, the user must 
verify encli tabular item via interaction with the seeuence 
development software before the new sequence package item 
marked "complete". 


The bottom graphic on Figure 3.3-1 shows the total tine 
line of an oNoeriment from upload of the commands to receipt 
of data. This graphic (and supporting tabular data) defines 
critical ti-'cs for oachj activity within a POI . If, for 
oNa-eelo, the hardware for an experiment is designed such 
thar It can onlv execute in one manner, there would 
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be one basic sequence package required during the entire 
mission, except possibly for the selection of redundant 
components. The experimenter presents the same seouence 
package every time he wishes to be active and only changes 
the times associated with the experiment for the appropriate 
POI. 

The user has the capability to designate a sequence package 

as a potential sr.^,uc:iiCe (as compared to a package which - . 

1 ' 

IS being utilized in the nominal POI activities by mission 
management) . This potential sequence may bo submitted to 
the validation software to determine if it is an acceptable 
Substitute for an existing package or addition to a POI. 

I 

If all validation shows the potential sequence package 
.acceptable, the user may update the actual lOS with the 
potential sequence packaoe to produce i new observatory 
sequence. The IC*^ s\ stem allows only ore user to update 
the lOS at a time. Requests to modify the lOS are accommodated 
on a priorit\ or Cirst-come-f irst-serve basis as mission 
requiiements specif\. The ic' svstem notiiios all active 
users when an lOS update is in progress. .Mternativol'^ , 
the potent! il sequence package n.iy be an adaptive sequence 
which IS trarsmitted onl% under .td.jptiv situations. 

The sequence p.nckaoe is used in the follovinq situations. 

. 1 . l,onq-ranoe planning; 

1. lliustiate observatoi\ vuound ti ick or other mission 
unieue j terns oJ interest sucli .is star fields and 
solar disks viewaoilit\ 

2. Doti-'o long i.inge predictions :or conditions such 
as oowei and tliei.mal 

3 . Show 11 noi oL'sc’ \ .1 toi \ events 


I 




b. Planning and scheduling: 

1. Define the POI 

2. ' Illustrate observatory ground track 

3. Show power and thermal proTCctions 

4. Show communications windows ~ 

5. Show experiment and subsystem events 

6. Provide data which is used to determine conflicts 
and gross capacity overloads. 

,1 

c. Command generation and validvition; 

1. Provide all data necessary to validate the 
integrated observatory sequence 

2. Provide all data necessary to pioduce integrated 
comnuind loads, on-board storage plans, OBC (or 
command memory) management and downlink plans. 

3.3.3 ,^daotlvo Update Capability 

Adaptive uodates are modi f ications made to the on-going 
observatory events or to the planned observatory sequences 
and command loads. Adaptive updates may be incciporated 
into the lOS or command loads prior to command transmx’-'sion , 
oi they may bo command sots transmitted in response to 
re.il-time data durmc actual contact with the observ atory*. 
Tor tlie first case, the lOS is routinely planned and 
qenerated and command loads are prepared. Dui uvj this 
oroeoss, e.ownlink data analysis ma\ cause a science 
experiiiientor or subsystem to require a change to the pvanned 
K'»S or command loads. The 1C** svstom allows for adaptive 
uodates to be incoiporatod into the lOS and command loads* 
generated and validated accordnglv . In the latter case, 
teal-time downlink data nuiv cause a science oxt'orimenter ei 
subsv stem to ’(.'guii,. an update to the on-coing obseivacorv 


sequence and commands to be uplinked during that contact. 

The IC"' system allows for pi ocanned commands to be trans- 
mittcd to affect the required update. 

The types of adaptive updates accommodated by the IC"^ 
system are summarized by Table 3.3-1. Sequence modifications 
are made to the lOS and have the potmtial tor impacting 
any observatory event. Parameter only modifications have 
little or no impact to other observatory events. Parameter 
only updates are made to the lOS or may be incorporated 
after command files are generated’. A parameter change 
update is a change to a paraimetei sequence that is currently 
scheduled in the lOS. Parameter change updates have no 
impact to any observatory events. A parameter xemove 
update involves deleting a parameter sequence that is 
currently scheduled in the lOS. Parameter remove updates 
may impact the OBC (ot command mcmots) if the coiiunands 
reside in the OBC (or conunand memory). However, the change 
requires only the replacement of the command with a co- 
operation code in the command load and is considered a 
minimum cbanao. A parameter add update iinolves addition 
of a paramotor seouonce to the lOS . Parameter add upilates 
ma\ impact tl:e OBC (or conunand memory) if the commands 
reside in tlio OBC (or command meraor\ ) and not the instru- 
ment / subs\ stem processor. Mso, since additional cenmands 
are to be uolinked, it is nocossci\ to verify that uplink 
ca’pacitN exists (i.o., the total numlior of commands to be 
trarsmitted does not i.’Xceed time available to transmit) 

Procannea commands are generated prior to a contact and 
arc available for t raiismi ''sicn during real-time operations. 

I 

Ml areca- "'ed conjnanrds are to be tr msmi.t ted witnin the 
available uelin.k cioacit' . Precanned idaptive commands 
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ADAPTIVE UPDATE IMPACT TO OBSERVATORY SEQUENCE 
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AND SAFETY 




are sequence modifications that potentially impact observatory 
events. The commands are generated prior to a contact 
and are validated by the P&S and CG&V processes. Precanr.ed 
adaptive commands are validated for all possible contacts 
that they are considered for transmission. Precanned 
parameter updates are treated as parameter additions and ' 
may be transmitted at any time provided uplink capacity 
and OBC (or command memory) capacity exist. Precanned health 
and safety commands are transmitted in event of instrument 
or subsystem anomalies. 

Figure 3.3-4 provides an overview of the adaptive update 

4 

capabilities provided by the IC system. The ma]or events 
to generate the lOS, generate and validate command loads 
and transmit the commands are shown in the order in which 
they occur operationally. The dashed lines indicate that' 
the events arc not conducted consecutively and that some 
period of time e.xists between them. Cut-off poxnts are 
identified which arc used to define update capabilities up 
to the specific point in time. 

Once the lOS is generated, it is available for some period 
of time prior to starting the CGSV process (cut-off point 
1). During this interval, each user ma^ modify the lOS 
for any type of adaptive update. The user has the capability 
to display the current lOS at the user interactive terminal. 
Using the lOS as a baseline, the user inputs lOS update . 
requests (e.g., add, delete, reschedule insfcrumont/subsystem 
sequences) . The user is restricted from altering seauences 
of other instruments/sabsystems . The user has the capabiliti 
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to activate the lOS generation software from the interactive 
terminal using the input update requests thereby generating 
a potential lOS. If no conflicts occur, the user requests 
that the potential lOS become the current lOS. If conflicts 
occur, the 10“* system does not allow the user to update the 
lOS- In a conflict condition, the user must ed^t the new 
inputs or coordinate with other users in order to affect 
modifications to remove the conflicts. The IC** system provides* 
displays which inform the user of the time available prioi to 
the CG&V process. If time runs out, the user is restricted 
from generating a new current IDS until CG&V has been completed 
for the contact of interest. — 

After the CG.tV process has been performed for a selected 
contact, -the corunand loads are 'available for a time period 
piior to the contact (cut-off point 2). If sufficient 

time exists to ma^e the change ,--the_user—has-the-capab-i-l-it-y ^ 

to modify the appropriate portion of the IDS and re-perform 
the CGiV process or to make parameter only modifications 
via CG&V. To modify the lOS, the user has the same 

* U 

cap>abil 1 1 aOS as defined above. However, since CG&V has 
. been performed, the uotcntial IDS does not become current 
until CG&V has been rcpea'ed. Once the lOS is conflict 
free, the user activates CG\V oiovidinc the potential 
lOS as input. If no conflicts occur, the user is allowed 
to uugrade the potential lOS to current. However, if 
conflicts occur, it is the usoi's rosponsibil it\ to make 
chances acoordinql^ . The IC* system informs the user 
of the time available pi lor tvo cut-off ooint 2. If the cut- 
of: p''>int IS exceeded, the user is restricted from making 


1 

I 

1 

} 



// 





5'7 


{ 


the lOS modifications and is limited to parameter only 
updates . 

Prior to the command window, the user may elect to make 
parameter only modifications provided sufficient time exists 
to implement the chaiige (cut-off point 3) . The user has 
the capability to interactively input the requests to add, 
remove or change parameters. The user then activates a 
portion of the CGsV process (refer to Section 3.4.3) in order 
to update the specific command load. If time runs out, 
the IC** system restricts the user from updating the command 
loads . 

During the contact, the user has the capability to select 
precanned adaptive corrimand loads from a list of commands. 

Each precanned load is identified relative to the contact- -*■ 
for vv.hicn it can be transmitted . For the case of pre- 
cannod adaptive commands, the commands may be validated 
for tiansmission during only one contact. For precanned 
parameter only commands, the loads may be transmitted 
during any contact. Precanned commands, as interacti /ely" 
selected by the user, are transmitted within the available 
command window (cut-off point 4) . 

3.3.4 In-Mouse Real-Time Oporatjons 

The IC"* s\ stem pro'-ides all users the capability to diiectiy 
perform selected real-time functions within the physical 
confines of the user in-house facility. The user’s in- 
)iousc facility ma^ bo either at a physieall^ remote site 
or the same physical location as the local operations.. 


N 
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Identical in-house capabilities are available to each user 
where these capabilities involve real-time monitoring of 
data and real-time instrument or subsystem control. However, 
it should be noted that selected users may not have a specific 
requirement to conduct real-time functions (monitor, control 
or both) from their in-house facility. The functional 

I 

hierarchy charts presented in Section 3.2 identify the 
in-house real-time responsibilities' for specific users. The 
real-time operations activity threads of Section 3.4.4 
describe the operationa] techniques. 

\ 

To perform the in-house real-time operations, the user 
interactive terminal is employed in a manner which allows 
( the user to interface with the local real-time opeiations 

! functions. Continuous voice communications during a contact 

exist between the in-house user (at the interactive terminal) 

1 and local operations personnel to allow discussions concerning 
science instrument/subsystem status or special observatory 
activities . 

The user has the capability to select any or all of the 
raw instrument/subsystem data as the data is available 
to the local operations functions. The user may select 
real-time and/or recorded observatory data. Prior to or 
during a contact, the user has the capability to input 
the required data options (c.g. instrument data selections 
and measurement IDs) to local ooerations. The reouests 

are input via inan-machine interactions with the user in- 
houso terminal. the data is received at the local 

operations facility, the requested user data is stripped 

i i ' 

: ! 

i’ I 
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out and passed to the user in-house faciJity. It is the 
user's responsibility to convert and process the raW data 
for possible display and analysis. The capability exists 
to restrict the user from selecting any aata pre-defined 
as sensitive. 

The user has the capability to select ’and display any of ythe 
local operations standard real-time data displays. Display 
requests are input to the interactive terminal via key- 
board entry or menu select. The user sees the displays as 

I 

the local operations personnel do. This is the standard , 
/in-house monitoring mode and the user is not required to 
process raw data or generate additional displays. 

The user has the capability to select for transmission 
precanned command loads that have been validated for a 
specific uplink or for multiple uplin’<s. Precanned 
command loads include: 

a. health and safety ccnmands ‘in event of aromalies 
D. adapt i”e science sequence commands 
c. parameter only modifications 

The user selects the desired commana load from a menu. 

Upon user request (via terminal entry) the selection is 
passed to local operations for implementation. During 
real-time operations, either the user in-house ooerations 
or the local operations have the capaoility to select the 
command loads out not ooth. Ho\.e'»er, local operations 
arc always responsible for the routinely planned commanding 
and have the capability to override or ignore the in-house 
user in ev'ent of anomalies. 
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3 . 4 Operational Activity Threads 


Section 3,1.2 of this document provides an overview of 
the IC"^ operational activities and defirTes four major 
command and control areas: long range planning, planning 

and scheduling, command generation and validation and 
real-time operations. Activity flows, of each of these 
areas are provided below. Tne acti/ity threads define che 
inter-relationships between the IC4 'system elements, 
illustrate the manner in which the system key features 
are utilized and provide the orde*' and timeliness in which 
the operations are performed. Ic should be noticed that 
downlink data analysis is not included in the activity 
threads as it is not considered a command and control 
function. 

* 

3.4.1 Long Range Planning Activities 


Long range planning (LRP) provides the "big picture" or 
synopsis of observ'acory operations. Long-range plans and 
objectives typically address major mission events such 
as launch dates, science interactions between mission 
observatories and major spacecraft/science instrument 
events which significantly impact observatory operations 
for some extended period of time. Depending upon mission 
needs, reguirements and comple.xities , LRP covers varying 
durations from the e'^tire length of the mission to a time 
period greater than the P&S POI. Tor some missions it may 
be nece.=-sary to oerform LRP on a regularly scticduled basis' 
dU'r to the complexity of spacecraft and science instrune.'^t 
op-arations; vhc-reas for other mi.ssions LR'’ is performoc 
orimaril_- prio'' to launch with infrequent uodates during 
mission onerations. 
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LRP IS a manual operation, whereby science and project 
representatives meet to address mission requirements. 
Consequently, LRP is not considered a driving factor to 
the command and control system and is not presented in 
greater detail in this document. 

3.4.2 Planning and Scheduling (P&S) 

3 . 4 . 2 . 1 Planning and Scheduling for a Period of Interest (POI) 

' / 

Figure 3.4-1 summarizes the P6S activitv thread. The 

I 

detailed ' icti’ and cnoabilicios are as follows: 


( 

a. Generate proiection data to support POI P&S - Init'ial 
condicions are available to start the P&S process. 

These include; the LRP, the lOS from previous POIs, 
any known event carried over from the previous POI 
and the TDRSS schedule. The'TDRSS schedule covers a 
time period greater than the POI-and is— f-inalized— by~the 
time actual planning begins for the POI. The TDRSS 
schedule is generated off-line to the normal P&S 
operations. Minor perturbations may arise during 
P&S, but the TDRSS schedule is coordinated in advance 
and available for P&S of the current POI. 

Each of t.ne subsystems generates projection data 
for the' POI using as input tnc pre"ious POI and 
projecting forward. The suos\stem data to be available 
include power and thermal DtoCiles, uplink caoacity 
for each contact (number of co~jtiands that car be 
transmitted) , downlink capacity (gross downlink data 
estimates) , prelini^ary data storage managcme.nt 
stratec and attitude and orbit nrec’icts. nisc, 

1 

( 

I 

1 
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mission management provides mission unique data Cor 
reference (o.g. star fields as function of attitude/ 
orbit, orbit day and night and South Atlantic Anomaly 
times) . The projection data are available for access 
by all users. 


b. 


c . 


Users access data to determine POI requirements - 
each of the users accesses the projection data (via 
user interactive terminals) to aid' in determining ^ 
individual POI requirements. Standardized data displays 
containing the projection data are available. 

Planning mooting - The purpose of the planning 
meeting is to establish major goals and objectives 
Cor the POI and to schedule observatory events that may 
cause major conflicts or perturbations on the obser’'atory 
or the ground.- tUssion m_anagemcnt is responsible for 
organizing and running the meeting. 


The users attend the meeting in person or "attend" from 
the user interactive terminals employing voice communi- 
■ cations. Remote users input requirements and display 
otner user requirements via interactive terminals. 
.Mission management and all users have the capability 
to interact ively build timeline displays for use during 
the meeting. The output of the planning meeting is 
summarized by mission management vine! is available for 
disolav to all users. 


d . l-'sers access data to generate seciionce requests.-' packages - 
Each user generates individual sequence package requests 
consistent with the planning meeting aqroemencs. These 
requests schedule the user sequences for the POI. The 


y 
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data from each user are available for automatic access 

by mission management. ^ i 

e . Mission management generates integrated observatory 

sequence - Mission management automatically accesses the 
user sequence requests/packagos and combines the data 
into the lOS. The outputs of this function are the 
preliminary lOS and associated conflict summaries. The 
mission management Sv Jtware checks for major conflicts 
between observatory events and compliance with uplink 
and downliniv. capacities. > 

f. Coordination session - A coordination session is 

held to review the lOS and resolve conflicts. Mission 
manageneit is responsible for organizing and running 
the session. 

The users attend the meeting in person or "attend" 
from the remote user interactive' tenninals employing 
voice communications . The users have the capability 
to display the preliminary lOS and conflict summary. 

The users modify their original inputs per the coordination 
session, and mission management re-runs the lOS generation 
software. ~ 

Ihe outout of the coordination session is the conflict 
free lOS . With the lOS as input, mission management 
activates the command generation and validation process. 

3 . 4 . 2 . 2 User Update Capability to Observatory Sequence 

Once the lOS is generated, tne capal:i’. it\ exists for tne 
users to adaptively update the sequences as described in 


65 


s 

section 3.3.3. This process is conducted by the user fcom 
the user interactive terminal. Figure 3.4-2 summarizes the 
process whereby the user modifies the lOS. The detailed 
activities are as follows: 

a. User access observ’atorv sequences - From analysis 
of received observatory data, the user derives a 
requirement to change the originally generated and 
cooroinated lOS. The user displays the lOS to determine 
the necessary instrument or subsystem changes. 

b . User inputs requests to add, remove, reschedule 
scnuences - The user has the capability to reschedule, 
add and delete any user unique sequences and to activate 

t ““ — — - - - — 

the mission management software to generate a potcntiaJ 
lOS based on the inputs. This activity is performed 

! from the user interactive terminal. 

c. Conf 1 ict-s - If conflicts occur in the ootontial 

’ lOS , the mission management function notifies the user 

v/ith a displayed message and restricts the user from 
continuing. If no conflicts arc detected ty the mission 
management function, step d is performed. 

d . Comna'^d generation and validation started checK - 

The user requests a status of CGSV to determine if the 
CG&V has started for any contact in the POI or if CG&V 
has started for the oortion of the lOS affected bv the 
proposed updates. 

e Ls ei ro.-uests im'pl inentat ion ot scoue n co update - 

1“ CGj-V nas not ktarted, the user requests that the 
oote ii.'-i lOS oe "ac'e tJie eui.v-nt lOS . Per tnis case, 

I ' ' 

I tnc '.:.ser h.'S Todlif-cd the IDS on a success oriented 

! bis IS without in\olvemcnt of mission management or 

I .. I , ' 

I other insti UT, one/ suDs\ stem personnel 

i 

I 

• ^ 
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FIGURE 3.U-2. USER UPDATE CAPABILITY 10 OBSER 

I 


i , 

i*U>OUT FH^IE ! 




LITY TO OBSERVATORY SEQUENCES 


rOLOOUT TRA-MB 









, f. Time available before uplink chock - If CG&V has 

started or been completed for the contact in question, 
the user requests status relative to time available 
to update the IDS (refer to Section 3.3.3). If time 
IS not available, the mission management function icstricts 
the user from continuing and the user receives a displayed 
message. 

i 

g . Activate command neneration and validation -If 

' time IS available, the user activa’tes the CC&V process 
using the potential lOS as input. 

h. Conflict check - If conflicts are detected, the 
mission management function notifies the ,'user with 
a displayed message and restricts the user from 

! continuing. ‘ 

1 . User requests implemertation of sequence update 
' and nc\/ CG&V products - If no con 1 . 1 rc’t's'occiTr'T' Che "user" 
requests that the potential lOS and new CGf.V products 
be made the current products. 

3 . 4_. 3 Command Generation and Validation 

3 . 4 . 3 . 1 CG&V for a POI 

The CG&V proce.ss is a fully automated activity w.nch is 
shown IP Figure 3.4-3 arid 3.4-4. 

a. I-iitiatio-^ of CGt,V j- An lOS is presented to the 

CGiV orocess after hav inq completed the. P&S activity. 

The IDS contains secucnce packages ‘'ron all Tc' elements 

' which are active dulring the time period to be validated, 

! I 

I 

I _ - 

i ” I 

i 

I « 
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FOLDOIi'T FRA^^H 






The time period over which the lOS is to be validated 
IS given as an input to the CGJiV initiation. Under 
. normal cycle activities the period is identical to the • 
POI. It IS possible, however, to run the CG&v process 
for other periods. A potential sequence modification 
may be presented to the CG&V process for validation. 

In this case, the period may' be shorter, than a POI , 
as some of the POI may be before any effecc^ of the 
modification or may have already transpired. 

Additionally, health and s>fety or adaptive sequence 
packages may be presented to the CG&V process to be 
validated against an existing lOS. Tnen, should the 
need arise, the sequences are available as prepackaged 
upload segments. - . 

Mission management sof tware ' schedules and controls 
the activities of the CG&V. l/here several activities 
are shown to run in parallel (i.e., power, thermal and 
on-board data storage analysis programs) , the actual 
execution aepends upon the pnysical conf igui ation . 

If all programs run in the same small computer, then 
they are run seauential 1/ . If all programs run in a 
large computer, they are started at once and the 
oper itirg system multiplexes between them. If any 
program is executed in a computer other than the mission 
management comouter , then the mission management soft- 
wuie is able to initiate the execution as well as 
transfer the necessary information to and from the 
remote computer. 

b. rceu fCments a-'ii sis - The poi.er recu irements 

a'^al^sis pioqrani is automvitically invoVod at the initiatioi 
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of CG&V unless specifically commanded otherwise. This 
program combines all power consumption values from the 
sequence packages to produce a required power profile 
for the observatory. Utilizing attitude and orbit 
information contained in the attitude and orbit subsystem - 
sequences if necessary for solar panel output analysis, 
the program determines if enough power is available 
throughout the POI. 

i 

Power control - The power control program generates 
any power subsystem commands necessary to produce an 
acceptable power profile. Such items as battery charging 
commands and shunt resister selections are generated 
at this time. 

Profile check - If an acceptable power profile 
cannot be generated, a message is sent to the mission 
management software to be forwarded to the originator 
of the CG&V run. (The oriqinacor is mission management . 
for normal cycle activities.) The power subsystem 
sequence package is marked incomplete and- the- CG&V 
process is not allowed to continue to further stages. 

If this IS a test of a potential new sequence, note 
that this failure does not effect the on-going POI. 
Included in the notification of an unacceptable power 
profile is the required power profile with the time 
period (s) of over capacity highlighted. 

Secuence incorporation - When an acceptable power 
profile IS achieved, the actual profile is logged into 
the system (as either actual or potential) and a 
pro3ection is updated for future POIs. The power 
subsystem sequence package which was received with the 
lOS - which may have been null except for rhe projected 
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power profile - is updated to reflect the actual profile 
and any commanding necessary commands, time of- 

execution and uplink rcquiiements) . The updated power 
subsystem sequence package is now part of the lOS, 

Theimal requirements an.»l\sis - The thermal rceuiremonts 
analysis program is automatically initiated in parallel 
to the power programs (step b above} . This program, 
combines all thermal load values from tne sequence 
packages to produce a required thermal profile for the 
observatory. Utilizing orbit and attitude infonriation 
contained in the orbit and attitude subsystem sequence 
packages to determine •■hormal loading values, the 
proqram determines if an acceptable thermal- prof ile 

f 

can be achieved throughout the POI. 

Theimal control - The tliermal control progiam generates 
any thermal subsystem co'nmands necessary to produce 

an acceptable thennal piofile. —Such- items-as— louver 

control comnunids and better cycling commands aie generated 
at this t ime . 

Pitirilt- check - If an acceptable thermal piotil; 
eaniiot bo generated, a messane is sent to the mission 
mana«.jement software to be forwarded to the originator 
of the CGikV run. (The originator is mission management 
foi normal cycle activities.) The thermal subsystem 
setiuence package is maiked incomplete and tlie CGi.V 
(M oeess IS not allowed to continue to tuither stages. 
Included in the notification ot an unacceptable theimal 
piofile IS the tequired thermal profile with thi' time 

I 

pel lod(s) ol ciorcapacity h4ghlighted. 

i 

I 
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1 . S>.?quencL? incorporation - When an acceptable thoimal 

profile IS achieved, the actual profile is logged into 
the system (as either actual or potential) and a 
projection IS updated for future I'OIs. The thermal 
subsystem sequence package which was received with the 
lOS - which may have boon null except for the projected 
thermal profile - is updated to reflect the actual 
profile and any commandinq necessary. The updated 
thermal subsystem sequence package is now part of the 
lOS, 

I 

j. On-board data storage analysis - The on-board data 
storage analysis program is automatically initiated 

in parallel to the power and thermal programs (steps b - 

and f above) . This program combines ao.! requirements 
for data storage in the common on-board storage (i.e., 
tape or bubble data storage device(s)) from the sequence 
packages to produce a required comraon data storage 

profile for the observatory. . The,, program -determines— 

the amount of data being stored and the times at which 
data IS to be stored. 

k. Sto rage control - The storage and plaiback planning 
software generates a storage map and playback plan. 

Events from prior POls are carried forward by the 
planning software. If storage control is performed 
on-board the observatory, this program duplicates the 
on-board technioue. The program di'velops a pLa\bac)v 
plan which takes into account the data receipt time 
requirements in the sequence packages. This program 
causes the data storaoo management sequence package to 
retlcct the required dow.link timing for all data 
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stored on-board. An index is generated which coordinates 
the originating users* sequence package to the downlink 
periods. The commands utiLised to control storage 
management .ind playback are generated by this program. 

l. Profile check - If an .acceptable on-board data 
storage profile cannot be generated, a message is sent 
to the mission management software to be forw.arded 

to the originator of the CG&V run. (The originator 
IS mission management for normal cycle activities.) 

The on-board data storage management sequence p.ickage 
IS marked incomplete .and the CG&V process is not .allowed 
to continue to further stages. Included in the 
notification of an un.acceptable storage profile is the 
required storage profile with the areas of conflict 
or overcapacity highlighted. The profile may be 
unacceptable because of too much data, multiple users 
exceeding the data acceptance late of the storage 
device or an unachiev.able dat.i receipt time. Except 
for the gross excess data problem (which normally would 
be detected during P 4 .S) most problems can be corrected 
by moving sequences slightly or leliev’iiig a too-soon 
d.it.a receipt requirement. 

m. t^equ.-nce moot porat ion - When an acceptable on-boa id 
data storage piofile is achieved, the actual profile 
IS logged onto the system (.is actual or potential) and 
a proiecfion for cairy-over use into the next POI is 
generated. The d.ita stoiago management sequence package 
which w.is received with the lOS - which may have cont. lined 
only those items cai ried ovoi from the piovious POI - is 
updated to retlect the .actual piofile and the commands 
necessary to .ichiove stoi.ige management and pl.i\b.ick. 

(The pl.iyback comm.invls mav be foi I'n-board use, ground 
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real-time use or a combination dopendinq upon the 
mission and observatory design.) The updated data 
storage management sequence li^ckage is now part of the 
lOS. 

3 . 4 . 3 . 2 CG&V for a Command Por..od 

a. initiation of CGt>V - At this point an the CGiV 
process, the lOS contains all information necessary 
to generate uplin)c and downlinl- schedules. This 

"U/L - D/L" trigger point is a mid-term holding point. 
The CG&V process may automatically continue from here 
to generate th«^ communicaiions plan for the entire 
I'OI or may be triggered periodically throughout the POI 
to generate communications events Cor a~ subpei lod such 
as a day or some mamber of orbjts. The choice as to 
which technique to use is mission unique and controlled 
by mission management. {The CG&V process may be 
continued to validate a full POI as- a potential to 
detect any xncompatabil itios and then -returned to the - 
"U, L - D/L" trigcer point for incremental execution 
to allow late changes to occur during the PCI.) 

b. Dy-^wnlink analxsis - The downlink analysis pi on ram 

(a support function of the con-imunications subs\stem) 
is initiated when a communications plan is required. 

The program is given a time period over which to operate 
which may be the entire POI or a subset of the POI. 

The downlink analysis combines the recorded playback 
leouiroments from tne data storage management sequence 
package, recorded playback requirements flora experiment 
controlled storage devices, memory dump requirements 
from OBC (or command memor\ ) sequence package and any 

I 

I 

I 
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real-time downlink requirements from all sources. 

This program generates an integrated, detail 
observatory required downlink profile. 

c. Downlink plan - The downlink planninct software, 
using the knowledge of the downlink windows contained 
,in the communications subsystem sequence package, first 
fits uniquely specified downlink requirements into the 
specified windows. Next, all downlinks are fit into 
downlink opportunities and a total downlink plan ,is 
produced. The downlink plan includes an inde.x which 
relates user sequence packages to selected downlink 

' windows such that all downlink content can be traced 

I 

back to the originating sequence. An\ on-board or 
I ground commands necessarv to achieve this schedule 

are generated at this time. 

d. Downlink plan cheek - If an acceptable downlink plan 
cannot be generated, a message is sent to mission 
management software to be forwarded to the origTnatoT 
of the CGi.V run. (The originator is mission management 
for normal cycle activicies.) The co.mmunications 
subsystem sequence package 'is marked incomplete and the 
CCjtV process is halted. Included in the notification 
of an unacceptable condition is the required downlink 
profile with areas of incompatibility highlighted. 

e. St^guonee uicoroorat i<->n - When' an acceptable downl ink 
plan IS achieved, the actual downlink profile is logged 
onto the system (as actual or potential) ind a proToction , 
for carry-over use into the ne.xt POl or subset of a 
POl IS generated. The communicat ions subsystem package 
which was received with the lOS - whicn mav have contained 
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only those items carried over from a previous POI 
or subset of POI - is updated to reflect the actual 
profile and the commands necessary to achieve the desired 
downlinks. (The downlink commands may be for on-board 
use, ground real-time use or a combination depending 
upon the mission and observatory design.) The updated 
communications subsystem sequence package is now part 
of the lOS. 

I 

3 . 4 . 3 . 3 CG&V wi t h completed power, thermal and data analysis 


a. Initiation of CG&V - At this point in the CG&V 

process (Figure 3.4-4), the lOS contains all information necessary 

to operate and receive data from the observatory. This 

vs called the "Parameter Add/Remove" trigger point 

because past this point, only pciraneter changes which 

do not affect power, thermal or data quantity can be 

made without redoing previous CG&V steps. Under normal 

CG&V activities, processing does not stop at this step- 

and therefore no specific initiation is required. 

The significance of t5ve "Parameter Add/Removo" trigger 
point IS that users may develop sequence packages which 
specify only parameter values for use in adapting 
instrument gains, scale factors, pointing, field of view, 
etc. to observed phenomenon. These parameters are 
constrained suc.h that they do not affect power, thermal 
or data generation on-board the observatory. Such parameters 
can be incorporated into the lOS directly by the user. 

Utilicing an interactive terminal, the ilser presents 
to the CG&V process a sequence package which contains 
the parametor(s) and desired uplink time frame. The 
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CG&V software informs the user whether or not an upli-nk 
window IS available and if there ^s enough time before 
the uplink to incorporate the new sequence package. 

If conditions are favorable, the CG&V process is executed 
from this trigger point on. 

OBC or command memory analysis - The OBC (or command 
memory) analysis program is automatically ' initiated after 
the downlink CG&V function is complete or upon command 
when a parameter change is to be validated. The anlysis 
program extracts all OBC (or command memory) commands 
from the lOS . These commands are in the form of mnemonics 
which are specified in user sequence packages for 
execution on-board the observatory. These commands are 
combined with those already on-board (held in a memory 
map or equivalent) and analyzed to verify that enough 
memory and time are available to execute the total 
command set. 


OBC or command momor\ .nanaocment - The management 
software converts mnemonics to actual commands and 
generates a time-sequential memory map or OBC activity 
profile which contains tne projection of activity (and 
memory content) for the period' of analysis. The period 
may be for the entire POI across several command periods 
or it may be for a subset of a POI. If the analysis^ 
period covers only one uplink, then only one memory map 
or OBC profile is generated. If over multiple uplinks, 
then sequential maps or profiles are generated. 

Plan check - If 'an acceptable OBC (or command memorv) 

I 

usage cannot be generated, a message' is sent to mission 

I 
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management software to be forwarded to the originator 
of the CG&V run. (The originator is mission management 
for normal cycle activities; however, any user could 
have entered a sequence package containing a simple 
parameter change.) The OBC (or command memory) 
management sequence package is marked incomplete, the 
CG&V process is halted and no outputs of this CG&V run 
are carried forward. The attempted map/plan is included 
in the failure message with the area(s) of incompatability 
highlighted. 

'e. Sequence incorporation - When an acceptable OBC 

(or command memory) usage plan is achieved, the memory 
map(s) or OBC activity profile (s) are updated to reflect 
current usage. The map/prof lie is projected into 
future time periods to reflect known usages. Additionally, 
the program calculates critical resource availability 
(such as memory available and computer time available) 
for ready access during real-time contingency or adaptive 
commanding activiries This program also updates the 
map/profile post-pass to reflect any real-time utilization 
of the available resources-* The OBC (or command memory) 
management sequence package is updated to contain all 
commands which are to be executed. (This is the summation 
of user specified as well as OBC (or command memory) 
subsystem specified commands.) l-Jhere required, these 
commands are grouped together into sets which 
must be transmitted contiguously. 


f. Uolink analysis - The uplink analysis program combines 

all commands which are to be sent to the observatory: OBC 

(or command memoiy) commands," commands to experiment 
or subsystem processors and real-time commands as 
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defined by the lOS. This program generates an integrated 
detail observatory required uplink profile. 


g. Uplink plan - The uplink planning software, using 
the knowledge of the uplink windows contained in the 
communications subsystem sequence package, first fits 
uniquely specified uplinks into specified windows. 

Ne.xt, all uplinks are fit into uplink opportunities 
and a total uplink plan is produced. An index is 
generated which relates uplinks to the originating 
sequence packages such that the uplink which contains 
commands from any sequence can be determined. 

h. Commanding plan check - If an acceptable uplink 

plan cannot be generated, a message is sent to mission 
management software to be forwarded to the originator 
of the CGiV run. The coiimunications sequence package 
is marked incomplete, the CG&V process is halted, and 
no outputs of this CG&V run are carried forward. The 
required uplink profile with areas of incompatioilit-v- - - 
highlighted is ’.ncluded in the error message. 

1. Sequence incorporation - When an acceptable uplink 

plan is achieved, the actual uplink profile is logged 
on the system (as actual or potential). Command packages 
are produced which contain all uplink values 
for a given uplink. The uplink content is indexed to 
the originating sequence such that given the sequence 
package identification, the uplink which contains the 
resulting commands can be determined. The command _ 
package specifies the order of transmission, which 
Items must be sent within a single upload sement and 
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which are to be sent only upon external stimuli, such 
as real-time or adaptive* uploads. ; 



% 

3. 4. 3. 4 CG&V with Completed Uplink Plan 

a. Initiation of CG&V - At this point in the CG&V 

process, the lOS reflects the total activity of the 
observatory and the commanding plan for a period of 
time. This is called the "File Update" trigger point 
as no changes can take place past this point except 
modification of the upload packages. (See paragraph 
3. 4. 3. 5 for a description cf such modifications.) 
Depending upon mission unique considerations, the CG&V 
process may automatically continue its activities at 
this time, or the process may halt at this point and be 
restarted shortly before the real-time uplink activities 
commence . 

0 *link File Generation - The command packaoe for a 
single uplink window is prepared for use by the real-time 
operations and the expected usage is logged onto the 
system. The command package is converted into individual 
upload packages (segments) which conform tc the format 
ano length conventions used by the real-time processes. 
Each segment is assigned an ID. Each segment is indexed 
such that given a sequence package, the upload segment 
which contains resultant commands can be determined. 
Normally a segment is to be transmitted in a specific 
uplink to achieve the desired activity for a POI; however 
a segment may be the result of a health and safety or 
adaptive sequence in which case it is kept on file 
until It IS required. The uplink profile for a command 
period IS generated. This may be for a single uplink 

I 
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window or a set of windows depending upon mission 
requirements. (The period may be varied within a mission 
depending upon such factors as the day of the week 
o scientific interest in a transient phenomenon.) 

'ihe profile is generated defining current upload window 
utilization# and projections for any upload segments 
that utilize subsequent windows t.re produced. For each 
uplink window the segments which are to be transmitted 
are identified and ordered. If there are segments 
which are to be transmitted only upon special command ir 
because of health and safety or adaptive science reasons, 
such segments are identified. The final step is to 
analyze the uplink window to produce a spare capacity 
measure to indicate the amount of adaptive commanding 
that can be performed by real-time operations. ~ 

3 . 4 . 3 . 5 Parameter Update Capabilities 

The CG&V late update activities and capabilities are shown 

in Figure 3.4-5. 

a. Initiation of CG&V parameter update - Each usef may 

define parameters which are used to modify the operation . 
of their instrument or subsystem which do not affect 
the overall activities during a POT. These parameters ~ 
are to be utilized -o react quickly to situations when 
a new sequence is not called for or time is not available 
to generate a new sequence. Such parameters as 
redundant component selectors, reset commands (if they 
do not effect data generated, power or thermal) , gains 
and scale factors are examples. The IC'^ system provides 
the capability for the user to have such parameters 
incorporated into uplinks from his terminal via a menu 
select activity. In order to add, remove or change 
such a parameter, the user commands the CG&V preoess 
to generate a file update. This activity occurs after 
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the upload segments have been generated for an uplink 
window. 

b. Parameter change - To command the CGSV process to 
change a parameter, the user inputs to the system the 
sequence package ID which contained the original para- 
meter (s), an image of the original parameter and the 

4 

new parameter. The CG&V process determines which upload 
segment contains the old parameter and determines if 
there is enough time to change the upload. {That is, 
has real-time operations already accessed the segment 
in question.) If the segment has already been trans- 
mitted, the user is informed of this fact; otherwise, 
the old parameter value (s) are replaced with the new values 
in the command package and the lOS version of the sequence 
package is updated. The change is treated as a post- 
pass modification for later incorporation by OBC (or 
command memory) management. The CG&V process then 
executes from the file update trigger point as was 
described previously. The originating user is notified 
tliat the change has been completed. 

c. Parameter remove - This activity is essentially 

the same as tne parameter change process except for the 
following point. The parameter to be removed is tested 
by CG&V software to determine if it affects OBC (or 
command memory) . If it does, then it is converted 
into a no-op rather than being removed from the commend 
package. (Note that changes at this point- change, 
add or remove- ere treated as real-time changes and 
are reflected in memory management post-pass.) 

d. Parameter add - To commend the CG&V process to add 
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a parameter the user inputs to feie system a desired 
uplink window and the parameter to be added. The CG&V 
process determines if the uplink has not yet occured, 
if there is sufficient time to modify the upload before 
transmission and if there is sufficient space in the 
uplink window to add the new parameter. , If the add is 
not possible, the user is so notified. If the change 
is executed by OBC (or command memory) , the available 
resource file generated during the normal CG&V process 
is accessed to determine if capacity exists. If the add 
IS possible, a dummy sequence package is automatically 
generated and associated with the lOS . The command 
package is updated to reflect the additional parameter (s) 
The CG&V process then executes from the file update 
trigger point and the originating user is notified 
that the addition has been made. The add is treated 
as a real-time act^v/ity and the memory map updated 
post-pass. ~ ' 

3.4.4 Real-Time Operations 

Figure 3.4-6 provides a synopsis of the real-time 
activities which outlines the local and in-house user 
-'rerations r.nd the interactions between each. These 
iciivities are described below. 

3. 4. 4.1 Local Operations 

The local operations are the focal point for all real-time 
downlink and uplink jactivities . Local operations are 
automatically controlled by the real-time procedure which 
is generated off-linje to the operations and is tailored 
to a specific contact. The real-tine procedure dri\es 
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data selection for display, data con^’ersron, data monitoring 
and command transmission. With these procedures manual 
intervention is required primarily to support anomalies. 
However, the capability exists for the operator to control 
manually many of the real-time functions. 

The local operations activities are as follows: 

a. Capture incoming data - All downlink observatory 
data enter the local operations facility. For real- 
time command and control activities, the prime data is 
the real-time data (data accumulated and transmitted 
real-time from the observatory) . However, recorded 

and tracking data are also received at the local operations 
facility. 

b. Select display data - The data for display is typically 
real-time data. However, the capability exists to 
display and monitor recorded observatory data. It may 
not be required or possible to display all of the data. 

This function automatically selects the appropriate 
data based on the real-time procedure. The operator 
has the capability tc manually request additional data 
parameters for display. 

c. Convert data to engineering units - The data for 
display IS converted automatically to engineering units 
according to conversion factors supplied by the system 
users. 

) 

d. Display data - Standardized data display formats 

are prepared ^nd displayed upon operator request. 

I 

( 
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Monitor data - Tho data monitor function is 


automatically controlled by the real-time procedure, 

but the capability exists for operator monitoring 

of the data. For the automatic monitor function, 

the downlink data is compared to alarm limits or adaptive 

response limits as defined in the real-time procedure. 

Alarm conditions and adaptive response conditions are 

flagged and, depending upon the procedure, a requirement 

- ' y 

may bo derived to transmit commands. 

I 

f. Requirement to transmit commands check - Based 

on the real-time procedure there may be a requirement 

to command the observatory . If there is no such- 

requirement, the downlink functions continue until the 
contact ends. 

One of the following types of comn'.ands may be required; 

1) preeanned anomaly coiTOnands._y 3 _re 3 ponse._to_ alarm 

conditions flagged by the- data monitor function; 2) standard 
cenmand loads as defined by the real-time orocedure; 

3) precanned adaptive commands as defined b\ the 
procedure and detected by the data mo*' itor function; 

4) precanned parameter only- commands as defined by the 
procedure and detected by the data monitor function. 

q. Anomaly check - An .anomaly is fl.agqed by the data 

monitor function, and the anomaly condition is automatically 
displayed to the operator. The real-time procedure 
(or the operator) determines if precanned safing commands 
aie available lor this condition. If commands are 
available, the procedure (or operator) causes tiro 
transmission to occur. The procedure (or operator) 
updates the, real-t.me procedure (if required) in response 


/ 


f 


to the anomaly and the downlink /uplink functions 
continue accordingly. Also, the operator notifies 
the appropriate off-line personnel of the anomaly. 

h. Standard command package check - The real-time 

procedure dictates the time(s) to transmit the normal* 
upload packages that were planned for the specific 
contact. The procedure (or operator) causes the 
appropriate command files to be, selected and transmitted. 
Anomaly procedures as described above are applicable 
if an anomaly occurs. The downlink data functions 
continue throughout the contact'. 

i; Adaptive requirement check - The capability exists 

to define in the real-time procedure specific downlink 
data conditions which, if occur, cause precanned adaptive- 
commands to be transmitted. These command loads are 
verified during the normal planning cycle as possible 

sequences to be commanded during a specific contact. 

The adaptive response requirement is llagged by the 
data monitor function, and this condition is automatically 
displayed to the operator. The real-time procedure 
(or operator) determines if sufficient OBC command or 
memory exists to accomodate the adaptive update. The 
operator requests a display of the OBC command or memory 
status to make this assessment. If there is sufficient 
time during the command window and the sufficient uplink 
capacity, the procedure (or operator) selects the appropriate 
commands and causes the commands to be '-ransmitted . 

The real-time procedure (or operator) causes the procedure 
to be updated accordingly, and the normal operation 
continues. If the adaptive commands are not transmitted 
according to the procedure, the operator notifies the 
user. 
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j. Parameter onl^' - Parameter only commands are similar 
to the adaptive commands with the exceptions that 
parameter only commands cause minimum or no impact 
to observatory events and can be applicable for all 
contacts. However, the process from the operations 
point of view is identical to the adaptive commanding 
technique. 

3. 4. 4. 2 In-House bser Operations 

The real-time in-house user activities parallel the local 

operations. The in-house user operations and activities 

are as follows: 

a. Select specific data - The user has the capability 
to select the raw telemetry data (real-time and/or 
recorded) for use during operations. The user inputs 
this request from the user interactive terminal, and 
the data is passed to the in-house facility 7 

b. Convert data to enoineerino data - If the user 
selects the raw data, it is the user's responsibility 
to decommutate and convert the data to engineering 
units . 

c. Displa% data - If the user seiects the raw data. 

It IS the user's responsibility to generate the data 
displays. The user has the option to request the local 
operations displays via the user interactive terminal. 

The user has a menu of display formats available and 
selects the displays from the menu. . 

d. Rcauirement to transmit command chock - The user 

■ I 

monitors the data displays to determir e command transmiss 


requirements. The user has the capability to request 
that the following types of commands be transmitted: 

1) precanned anomaly commands, 2) precannsd adaptive 
commands, 3) precanned parameter only commands. If no 
commands are to be transmitted, the user continues the 
data monitoring functions. 

Anomaly check - The prime responsibility for anomaly 
commanding resides with local ' operations. However, 
isolated instances may arise where the user has responsibility 
to trigger anomaly commanding (i.e., back-up to local 
operations or user instrument anomalies that occur while 
user is requesting adaptive commands) . If the IC** 
system recognizes the user responsibility, the user may 
select the appropriate precanned commands from a menu 
of responses and input the request to local operations. 

Precanned adaptive and parameter only check - T’he 
user has the capability to trigger “adaptive" and7or ' 
parameter onl^ commanding provided the IC* system 
recognizes this responsibility.' The user has available 
a menu of precanned adaptive and parameter only command 
loads. Where required, these loads are restricted 
for spev^ific contacts. The IC4 system accepts the 
command requests provided OBC (or command memory) and 
uplink capacity are available and provided the command 
window exists. The user selects the precanned commands' 
and the request to local operat.\ons is input via the user 
interactive terminal. If the IC‘- system does not accept 
the command request, the user is notified via an automatic 
display. The user continues to monitor the data throughout 
the contact. 


// 

// - 


I 


92 


3.5 Interfaces 


Figure 3.5-1 summarizes the data interfaces between the 
4 

ina]or IC system elements. These functional interfaces 
show the elements that develop data and that utilize the 
data. Figure 3.5-1 shows generators and users of data 
and IS not intended to define the actual manner in which , 
data are transferred within the system. It should be 
noted chat only those interfaces to support command and 
control activity are shown. 

The IC^ interfaces are defined in detail in Tables 3.5-1 
through 3.5-30B. For each interface, the originating 
and receiving functions are identified where the functions 
are referenced to the functional hierarchy charts (Section 
3.2). The type of interface (or functional architecture 
technique) is defined as one of the following categories 
of interfaces: --- - 

a. person-to-person 

b. man-machine 

c. machine-machine. 

Person-to-person interfaces address information passed 
between people. These interfaces consist of: 

a. face-to-face interfaces (i.e. meetings) 

b. voice communications (via mechanisms) 

c. notes and memos. 

Man-machine interfaces include those interfaces where man 
interacts with an automated device (i.e., terminal and 
CRT) to input or receive information. The following types 
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of man-machine interfaces are considered: 


a. man directs activity of the machine (i.e./ man 
activates programs, man replaces data sets, man 
requests data displays) 

b. data display (data is visually presented to, the man) 

c. data entry (man inputs data/information in response 

to program requirements/prompts, man originates data 

sets) . V 

/ 

Machine-machine interfaces address automatic interfaces 
(no man-in-tbe-loop) that occu’. between programs and 
machines. These include: 

a, automatic triggers (machine triggers execution 

of an activity /program based on time, availability 
of data or successful completicn of a previous 
activity) 

b. data access (machine /prog ram access defined dat'a' 
from another program or interface) . 
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